Flow control in umts using information in ubs field

ABSTRACT

Each of a plurality of data frames transmitted from a first node to a second node carry information belonging to one of a plurality of data flows. A determining unit determines at periodically repeated times, for each of the data flows, whether there are more data frames in the first node waiting to be transmitted. A capacity allocating unit allocates for each of those data flows for which no data frames have been waiting to be transmitted for a predetermined time period only a small amount of the totally available bandwidth for transmission from the first node to the second node. It also allocates for each of the remaining data flows a share of the rest of the totally available bandwidth such that the sum of the shares for all said remaining data flows is equal to the rest.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/064,902, filed Sep. 17, 2008, which is the National Stage ofInternational Application No. PCT/SE2005/001247, filed Aug. 26, 2005,the disclosures of which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to flow control for transmission of dataframes from a node to another node, in particular a network including afirst node and a second node or a data transmitting node and a datareceiving node, and a method of transmitting data frames from a firstnode to a second node.

BACKGROUND

The universal mobile telecommunications system (UMTS) is a networktechnology allowing transmission both of voice and high-speed data. Itis part of the third-generation (3G) wireless standards, as specified bythe Third-generation partnership project (3GPP). Wideband code-divisionmultiple access (WCDMA), also called wideband CDMA, is one method forradio transmission used in UMTS. UMTS is a development of GSM/GPRSsupporting packetized voice and data transmissions.

The method called high speed downlink packet access (HSDPA) is anenhancement of UMTS for increasing the capability of transmitting data,resulting in a reduced cost per transmitted bit and a greater spectralefficiency, in addition to significant improvements in downlink dataspeeds. HSDPA can give improvements of at least two to three times thecurrent capacity. It is based on the WCDMA standard and uses the samespectrum. HSDPA uses quadrature phase shift keying (QPSK) and16-quadrature amplitude modulation (16QAM).

The HSDPA method uses a distributed architecture in order to achieve alow delay link adaptation by performing the most important process stepsin the radio base stations (RBSs) and thus close to the air interface,see FIG. 1. HSDPA uses well established processing steps, including fastphysical layer (L1) retransmission for faulty packets, combining andlink adaptation techniques, to obtain improved packet data transmission.

The HSDPA process steps basically include:

-   -   scheduling in the radio base stations for the downlink packet        data operation;    -   higher-order modulation;    -   adaptive modulation and coding;    -   hybrid automatic repeat requests (HARQs) for retransmissions;    -   physical layer feedback of the momentary channel condition; and    -   transmission in a high-speed downlink shared channel (HS-DSCH)        allowing several users to share an air interface channel.

In the following some important features of HSDPA will be described.

1. Adaptive Modulation and Coding

HSDPA uses advanced link adaptation and adaptive modulation and coding.

2. Fast Scheduling

In HSDPA data traffic is scheduled in the radio base stations. HSDPAuses information on channel quality, terminal capabilities, quality ofservice (QoS), and power/code availability to achieve efficientscheduling of data packet transmissions.

3. Fast L1 Retransmissions

When a link error occurs, a mobile terminal immediately requests theretransmission of the lost or erroneous data packets. This operation isdenoted as a method including hybrid automatic repeat requests (HARQs)for reducing the delays in and increasing the efficiency ofretransmissions. HARQ control is performed in the radio base stations,as illustrated in FIG. 2.

4. Channel Quality Feedback

In the radio base stations, according to the HSDPA method, estimates ofthe channel quality of each active user are collected and used. Thisfeedback provides current information on a wide range of channelvariable physical layer conditions, including power control, acklnackratio, QoS, and HSDPA-specific user feedback.

5. High-Speed Downlink Shared Channels (HS-DSCHs)

HSDPA operation is carried in high-speed downlink shared channels usinga frame length of only two milliseconds, compared to frame lengths of10, 20, 40 or 80 ins used in previously used downlink shared channels(DSCHs). Such downlink shared channels are downlink transport channels,each of which may be shared by several user equipments. A downlinkshared channel is used to carry dedicated control or traffic data fromthe SRNC (Serving Radio Network Controller). A DSCH will be associatedwith one or several downlink DCHs (Dedicated Channels). The HS-DSCHsprovide 16-level quadrature amplitude modulation (16-QAM), linkadaptation, and the combining of retransmissions in L1 with HARQs. HSDPAuses high-speed shared control channels (HS-SCCHs) to carry the requiredmodulation and retransmission information. Uplink high-speed dedicatedphysical control channels (HS-DPCCHs) carry automatic repeat request(ARQ) acknowledgement messages, provide downlink quality feedback andtransmit other necessary control information in the uplinks.

HSDPA requires a flow control algorithm or method that controls thetransmission of data frames in an HS-DSCH, as specified by e.g. TS25.401 from 3GPP, between a radio network controller and a radio basestation. The algorithm for flow control is not standardized, but controlmessages, e.g. the message “Capacity Allocation”, are standardized. Inorder to manage the flow control, the RBS calculates the allocations tobe carried in the “Capacity Allocation” messages sent to the RNC, andthe RNC sends data frames in the HS-DSCH to the RBS according to theinformation in the “Capacity Allocation” messages, one allocation ofcapacity for each flow of data. When there is more data to send from theRNC, the information element (IE) “User Buffer Size” (UBS) in theHS-DSCH data frames is larger than zero. When the data frame has emptiedthe RNC buffer for the respective flow of data, UBS is set to zero.

The flow control algorithm has to manage limitations for both theair-interface and the Iub HS-DSCH bandwidth, Iub being the interfacebetween an RNC and an RBS.

More particularly, the transfer of a data frame in an HS-DSCH from anRNC to an RBS is made in the following way. After the RNC has beengranted capacity by the RBS, as obtained from a capacity allocationcontrol frame or from an initial capacity allocation control framereceived from the RBS, as described in 3GPP TS 25.433, and the RNC hasdata waiting to be sent, the data frame is used to transfer the data inthe HS-DSCH. If the RNC has been granted capacity by the RBS using theinitial capacity allocation control frame as described in 3GPP TS25.433, this capacity is valid for only the first data frametransmission in the HS-DSCH. When data is waiting to be transferred, anda capacity allocation control frame has been received, a data frame inthe HS-DSCH will be transmitted immediately according to the receivedallocation, i.e. using the bandwidth corresponding to this allocation.Each data frame sent in an HS-DSCH includes the information element“User Buffer Size” to indicate the amount of data pending for arespective flow for an indicated priority level.

SUMMARY

It is an object of the invention to provide an efficient flow controlalgorithm.

It is another object of the invention to provide a flow controlalgorithm that considers the fact the data flows can be inactive, i.e.that for some time periods there may be no more data in the flows to betransmitted.

A flow control method, also called flow control algorithm or flowcontrol function, is proposed that has states stored per radio basestation. If such states are not stored per radio base station thedetection of inactive users is not needed. However, storing such flowcontrol states per radio base station can result in a better transportnetwork utilization. In the method as proposed herein the value of theinformation element “User Buffer Size” is used for the flow control.Priority queue flows for which data are waiting to be transmitted get acalculated or estimated capacity allocation, i.e. a highest possiblebitrate for transmission, considering the number of priority queue flowsand conditions in neighboring networks, and priority queue flows forwhich no data have been waiting to be transmitted for a predeterminedtime period get a “background” or minimum predefined capacity allocationvalue.

An advantage of this method is that only active priority queue flowscompete for the available bandwidth, whereas inactive priority queueflows only use very small capacity allocations. Otherwise, if allpriority queue flows would be given the calculated or estimated capacityallocation, i.e. bandwidth or bitrate, some part of the totaltransmission capacity available for the considered type of datatransmission would be wasted, said part corresponding to that bandwidththat is reserved for the inactive priority flows.

The purpose of using such minimum capacity allocations for inactivepriority queue flows is to avoid using the sequence of first sending amessage with a capacity request sent from the radio network controller,this resulting in that a capacity allocation message is sent from theradio base station to the radio network controller before data can bestart to sent from the radio network controller to the radio basestation. The inactive priority flows, i.e. flows for which no data iswaiting to be transmitted, are detected by considering the value of theinformation element “User Buffer Size”, storing states per priorityqueue and using inactivity timers.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described by way of non-limiting embodimentswith reference to the accompanying drawings, in which:

FIG. 1 is a schematic of communication between a radio base station anduser equipments using high-speed down-link data transmission,

FIG. 2 is a schematic illustrating differences in data transmission touser equipments using a shared downlink channel according to twodifferent methods,

FIG. 3 is a diagram illustrating transmission of data from anapplication server to an application running in a user equipment usingHSDPA and a flow control function for control of Iub,

FIG. 4 is a diagram illustrating different layers in communicationbetween an RNC and an RBS using HSDPA,

FIG. 5 is a transmission diagram illustrating a principle for flowcontrol using standardized messages,

FIG. 6 is a schematic illustrating buffers in an RNC, an RBS and a UE,

FIG. 7 is a diagram illustrating calculation of the state of a priorityqueue flow,

FIG. 8 is a state machine of changes of the state of a priority queueflow, and

FIG. 9 is a schematic of a radio base station illustrating a flowcontrol unit and related memory cells.

DETAILED DESCRIPTION

The general flow of information in a system built according to UMTSincluding both a mobile telephony network and some other network, forinformation transmitted from the other network to a user equipment (UE)in the mobile telephony network, using high speed downlink packet access(HSDPA), in particular the flow between a radio network controller (RNC)and a radio base station (RBS) in the mobile telephony network, will nowbe described with reference to FIGS. 3-6. These figures include mainlyonly units and functions that are relevant to or needed for said generalflow of information.

Many packet data applications use the standardized transmission controlprotocol (TCP), as specified by IETF, for transmitting data. As seen inFIG. 3, data, such as an Internet page, can e.g. be sent from anapplication server 101 through a public data network (PDN), also calleda general purpose network or general network 103, such as the Internetto an application 105 running in a user equipment 107, i.e. a mobileterminal. The IETF transmission control protocol has a window size ofits own, which limits the number of bytes in the different buffers thatthe data has to pass between the application server 101 and the userequipment. The radio link control (RLC) sublayer has another windowsize. Automatic repeat request (ARQ) acknowledgement messages are usedboth according to TCP and in the RLC sublayer for controlling thecorrectness of transmissions.

The general purpose network 103 is connected to the mobile telephonysystem 104 at a gateway or support node 109, for GPRS this nodeincluding a gateway GPRS support node (GGSN) and a serving GPRS supportnode (SGSN). The gateway GPRS support node is in GPRS a router thatserves as a gateway or interface between packet data networks and mobiletelephony networks, in particular between a packet data network such asan internet protocol (IP) network (103) and a serving GPRS support nodein the mobile telephony network 104.

The interface between a core network and a radio access network (RAN) isgenerally called Iu and the packet-switched interface between an SGSNand an RNC 111 is called Iu-PS. The interface between the RNC and an RBS113 is called Iub and the interface between the RBS 113 and the mobileterminal 107 is called Uu.

Packets received from the gateway or support node 109 are first storedin SDU buffers 115. IP packets are stored here, which because of RLCprotocol reasons, in particular sequence number limitations, cannot bestored in the RLC buffers.

Then, in the RNC 111 the information to be sent to an RBS is dividedbased on terminal and radio base station capabilities, subscriptiontype, radio conditions and possibly QoS requirements, in data to betransmitted in dedicated channels and data to be transmitted in a sharedchannel, the latter type of data being that considered here.

A flow control (FC) function is used for controlling communicationbetween the RNC 111 and the RBS 113, in particular the flow of dataframes in the HS-DSCH, using the Iub interface and has the purpose ofkeeping priority queues (PQs) 127 in the RBS short and not to overflowthe Iub transport network, i.e. the transport network between the RNCand the RBS, see the network portions 119, 121 in FIG. 3.

Iub Architecture for HSDPA

The flow control function includes portions 123, 125 located in the RNC111 and in the RBS 113, respectively. In the RBS it is a part of theMAC-hs (Media Access Control for HSDPA) function 126. It interacts,using Iub protocol messages carried in Iub control frames, with the flowcontrol portion 123 in the RNC that is part of the MAC-d (Media AccessControl, dedicated channels) function 124 in the RNC 111, see also FIG.4.

The flows that are controlled by the flow control function 123, 125 arethe flows of MAC-d protocol data units (PDUs), carried in HS-DSCH dataframes according to the Iub frame protocol (FP).

Each MAC-d PDU arriving to the portion 125 of the flow control functionin the RBS 113 is stored in one of the priority queues 127, waiting tobe selected by the scheduler function 129 of the RBS for transmissionover the Uu interface to the user equipment 107.

In the RBS 113 one priority queue 127 is provided for each HS-DSCHMAC-hs connection of the connected user equipments 107 and onecontrolled flow of MAC-d PDUs is provided over the Iub interface to eachpriority queue. Each such flow is in the flow control function denoted apriority queue flow (PQF). A priority queue flow is defined as packetsarriving for the same user having the same contents of the “CommonChannel Priority Indicator” (CmCH-PI) field, as defined in standarddocuments. In practice, in most cases there is for each user equipmentat each instant only one priority queue flow that is the downlinktraffic flow for the respective user, though generally there may be aplurality of priority queues for each connected user equipment 107.

Each priority queue flow is transported over the Iub interface by oneinstance of the Iub frame protocol (FP) using a dedicated AAL2 (ATMAdaptation Layer No. 2) connection as transport bearer.

FIG. 4 illustrates the layer configuration and corresponding units ofthe Iub and Uu interfaces.

-   -   The radio link control sublayer portion 401 of the RNC 111 has        the main purpose of ensuring a loss-free, i.e. reliable, link        over the radio interface for TCP based data transfer. It        provides reliability using error detection and recovery by        retransmissions. The RLC does segmentation and reassembly of        higher layer PDUs. Thus, if only a small part of a PDU has been        lost, the full PDU must not be retransmitted. This way the        end-to-end congestion control algorithm must not react to the        changing radio conditions. The RLC 410 communicates with a radio        link control sublayer portion 402 included in an RLC/MAC-d        portion 133, see FIG. 3, of the user equipment 107.    -   The MAC-d function 124 in the RNC 111 communicates with an MAC-d        function 403 included in the RLC/MAC-d portion 133 of the user        equipment 107, see FIG. 3. Furthermore, the MAC-d function of        the RNC 111 is here illustrated as including an HS-DSCH FP        (Frame Protocol) handling unit 404. This frame protocol handling        unit in turn includes the flow control portion 123 and        communicates with the flow control portion 125 included in an        HS-DSCH FP handling unit 405 of the MAC-hs function 126 of the        RBS 113. The MAC-hs function of the RBS includes the flow        control portion 125, the scheduler 129 and the MAC-hs FIARQ        function 131, see FIG. 3. The MAC-hs function 126 in the RBS        communicates with the MAC-hs function 135 in the user equipment        107. The MAC-hs function of the user equipment includes an HARQ        function 136, see also FIG. 4, communicating with the MAC-hs        HARQ function 131 of the RBS 113.    -   The AAL2/ATM VC layer having portions 407, 409 in the RNC 111        and the RBS 113, and    -   The physical layer (L1) portions 411 in the RNC 111, 413, 415 in        the RBS 113 and 417 in the UE 107.

For the communication between the RBS 111 and the RNC a transportnetwork 419 such an ATM network and/or a PDH/SDH network is used,compare the transport network portions 119, 121 of FIG. 3. For thecommunication between the RBS 111 and the UE 107 a wireless network 421is used.

Flow Control Messages Between RNC and RBS

HSDPA data, i.e. MAC-d PDUs, are sent from the RNC 111 to the RBS 113.Each MAC-d flow of a given priority level is equal to one priority queueflow and is represented by one queue 117 in the RNC and one queue, apriority queue 127, in the RBS. A number of MAC-d PDUs are sent in eachHS-DSCH FP data frame, belonging to the same MAC-d flow.

Data frames sent over Iub for each priority queue flow is flowcontrolled using capacity allocation (CA) messages, sent in controlframes from the RBS 113 to the RNC 111, see FIG. 5. A capacityallocation message specifies, as given by a combination of parameters,the maximum bitrate. i.e. the maximum number of MAC-d PDUs that areallowed to be transmitted during a predetermined time period for theconsidered priority queue flow. From such a message a minimum repetitionperiod can also be obtained.

For a simple case the RBS 113 decides, based on the filling level of therespective buffer, i.e. the length of the respective priority queue, inthe RBS, on air interface conditions, i.e. conditions related to the Uuinterface, and on transport network congestion in Uu, the bitrate thatshould be allocated for the given priority queue to be used by the RNC111 for transmission in the respective HS-DSCH. The RNC shapes dataflows according to the last received capacity allocation messages.Message structures can be found in the document 3GPP TS 25.435, inparticular FIG. 21A, “Data Frame”, and FIG. 36, “Capacity Allocation”,and the accompanying text.

The flow control function 123, 125 is aware of the average data rateavailable for a priority queue flow on the air interface between the RNCand the RBS or at least an estimate of said average data rate. It alsoknows the number of PDUs from that priority queue flow which are waitingin the RBS buffer for this queue 127. Based on this information the flowcontrol function can decide to change the allocated rate of theconsidered priority queue flow. The main goal is to keep a target numberof PDUs waiting in the RBS 113, i.e. not too many and not too few PDUsin each of the priority queues.

There is one RLC queue 117 per priority queue flow in the RNC 111 andone Mac-hs queue, i.e. priority queue 127, per priority queue flow inthe RBS 113.

The buffers for the queues 117, 127 are designed in such a way that PDUsare most probably lost only in the transport network of Iu or in the airinterface of Uu.

Purpose of Using a Flow Control Function

Iub traffic flows in HS-DSCHs are flow controlled by the flow controlfunction 125 of the MAC-hs 126 in the RBS 113. The Iub protocol messagesthat can be used for flow control are specified in 3GPP TS 25.435 (Iub).The flow control function itself is not standardized.

The purpose of the flow control function is to keep an “appropriate”amount of MAC-d PDUs buffered in the RBS 113, i.e. to keep the RBSpriority queues 127 short enough for RLC retransmissions but long enoughto ensure throughput when scheduled.

The same logical RLC buffer for the priority queue flows can be seen asdistributed over the RNC 111, RBS 113 and UE 107. The MAC-d PDUs to beretransmitted have a higher priority in the RNC than PDUs that are to besent for the first time from the RNC, see FIG. 6. Therefore the RLC RBSportion, the priority queues 127, shall be “short” or not too long, thisbeing one reason to use a flow control function for controllingtransmission in the HS-DSCHs from the RNC 111 to the RBS 113.

HS-DSCH traffic is carried over a “best effort” type of quality ofservice (QoS) in the transport network 119, 121; 415 between an RNC andan RBS. The flow control function shall regulate the HS-DSCH trafficflow in such a way that loss of MAC-d PDUs, due to too long Iubtransport delays, such as caused by overload of the transport network,becomes appropriate. There is a trade-off between having a high frameloss combined with a high bandwidth utilization and a low frame losscombined with a lower bandwidth utilization.

There are mainly two bandwidth capacity bottlenecks for HSDPA traffic inthe transport networks between the RNC 111, the RBS 113 and the UE 107,both which must be considered in the flow control function:

-   -   Iub interface    -   Radio interface in Uu

A flow control function including a special method of allocatingcapacity for users, using “user states”, will now be described withreference to FIGS. 7 and 8. These variables “user states”, also calledflow control states or priority queue flow states, are stored in theradio base station for each current user. In particular, detection ofinactive users is used. This capacity allocation method can result in abetter utilization of the transport network for Iub.

The method uses the current value of the standardized informationelement “User Buffer Size” (UBS) for each user for accomplishing theflow control. Priority queue flows having (User Buffer Size)>0 gets acalculated capacity allocation and users having (User Buffer Size)=0during a predetermined time period, gets a “background” or minimumcapacity allocation.

The user states, denoted pqfStates, are thus defined to have either oneof the states active or inactive, these states denoted activePqf andinactivePqf. A user that has an inactive priority queue flow, i.e. forwhich its pqfState=inactivePqf, does not compete for the available HSbandwidth in transmissions between the RNC and the RBS. Such a user getsa predefined capacity allocation with the purpose of being prepared whendata is to be sent from the RNC, without the need of using a capacityrequest control frame. This predefined capacity allocation does notconsume any significant portion of bandwidth taken from the calculatedcell HS bitrate.

For a user that has an active priority queue, i.e. for which itspqfState=activePqf, there are more data to be transmitted. This isindicated by the fact that the information element “User Buffer Size” islarger than zero. The information element “User Buffer Size” is includedin HS-DSCH data frames as standardized. Such a user having an activepriority queue flow gets a calculated capacity allocation bitrate.

An inactive priority queue flow, i.e. for which itspqfState=inactivePqf, is a priority queue flow with a “context”, i.e. apriority queue flow for which a priority queue 127 exists in the RBS113, but for which there are no more data to be currently transmittedfrom the RNS 111. An active priority queue flow is set to be inactive,i.e. it gets its state changed to inactivePqf, if the informationelement “User Buffer Size” for this queue has been equal to zero for aperiod longer than a predefined time, denoted ubsZeroTime.

The capacity allocation method uses as input this fixed parameterubsZeroTime that is hard-coded and the information element or variable“User Buffer Size” for each existing priority queue flow. The methodproduces as output the variable pqfState for each existing priorityqueue flow. The information element “User Buffer Size” is, asstandardized, sent by the RNC 111 and indicates the amount of data thatis available in the RNC, or is traveling towards the RBS 113, afterhaving received an HS-DSCH data frame or capacity request.

For each of the priority queue flows or at least for those of thepriority queues that have been assigned one, a UBS inactivity timer isincremented every 2 ms TTI.

For an active priority queue flow:

1. as long as “User Buffer Size”>0, the variable pqfState for the userof the priority queue flow remains equal to activePqf.2. as soon as “User Buffer Size” becomes equal to zero, a UBS inactivitytimer for this flow is reset and started. If “User Buffer Size” has beenequal to zero for the predetermined time period ubsZeroTime, thevariable pqfState is set to inactivePqf. If “User Buffer Size” becomeslarger than zero before the UBS inactivity timer has expired, thevariable pqfState remains equal to activePqf.

For an inactive priority queue flow:

1. as long as “User Buffer Size” is equal to zero, the variable pqfStateremains equal to inactivePqf.2. if “User Buffer Size” becomes larger than zero, the variable pqfStateis set to activePqf.

As seen in FIG. 7, in the RBS 113, at each time when a data frame isreceived from the RNC 111, the UBS is extracted and the inactivitytimers are incremented. The state of the priority queue flow having datain the received data frame is calculated in a state calculation function701. A state machine of the state calculation function illustrates, asseen in FIG. 8, that each priority queue flow can take either an activestate 801 or an inactive state 803.

Thus, at reception of an HS-DSCH data frame from the RNC 111, the newUBS is compared to zero.

An active priority queue flow can have the variable UBS larger than zeroor equal to zero, see the vivid substate 805 and the waiting substate807, respectively.

-   -   If the previous UBS for the active priority queue flow was        larger than zero, i.e. the priority queue flow taking the vivid        substate 805, and the new UBS is equal to zero, the waiting        substate 807 is instead taken in which the UBS inactivity timer        is reset and started.    -   If the active priority queue flow is in the waiting substate 807        and the new UBS is larger than zero, the vivid substate 805 is        instead taken.    -   If the active priority queue flow is in the waiting substate        807, the new UBS is equal to zero and the UBS inactivity timer        is larger than or equal to the parameter ubsZeroTime, the        priority queue flow becomes inactive and takes the inactive        state 803.

An inactive priority queue flow is always in the state 803 but when thenew UBS is larger than zero, it becomes active and passes to the vividsubstate 805 of the active state 801.

In the calculation of capacity allocation for active and inactivepriority queue flows the air-interface HS estimated bitrate is comparedto the available Iub HS traffic bandwidth. The calculated capacityallocated bitrate, denoted caCalcBitrate, for each of the activepriority queue flows is the minimum of the air-interface and Iubbitrates available for the considered priority queue flow. The Iubbitrate is calculated by dividing the estimated available Iub capacityfor all priority queues among the different priority queues. An exampleof the calculation method can be found in the simultaneously filedInternational patent application, “FLOW CONTROL IN UMTS”, forTelefonaktiebolaget L M Ericsson, inventors Peter Lundh, SzilveszterNadas, that is incorporated by reference herein.

Inactive priority queue flows get a minimum CA Bitrate, denotedminCaRate, and thus do not use any significant capacity from the commonTub capacity pool. It can be so small that there is no need forreservation.

The calculation of capacity allocation for active and inactive priorityqueue flows uses as inputs the parameter minCaRate and the variablepqfState for each currently existing priority queue flow. It produces asoutput the variable caCalcBitrate. The calculation is given by thefollowing pseudo-code:

IF pqfState is activePqf, THEN calculate caCalcBitrate normally ELSEcaCalcBitrate = minCaRate

For performing the flow control function a flow control unit 901 andsome memory cells have to be introduced in the RBS 133 as seen in thediagram of FIG. 9. The memory cells include, for each priority queue 127and hence for each priority queue flow a memory cell 903 for storing thevalue of the variable pqfState and a memory cell 905 for storing the UBSinactivity timer. Also there is a memory cell 907 for the fixedthreshold value ubsZeroTime. The flow control unit 901 includes a unit909 for incrementing the UBS inactivity timers stored in the cells 905,a comparator 911 for comparing UBS of a received data frame to zero, aunit 913 for changing the value of the variable pqfState stored in oneof the cells 903 when required, a unit 915 for resetting and startingone of the UBS inactivity timers stored in the cells 905 when required,a comparator 917 for comparing one of the UBS inactivity timers storedin the cells 905 to the fixed value of ubsZeroTime when required, and aunit 9191 for calculating, based primarily on the number of priorityqueues for which the variable pqfState has the value activePqf, but alsoconsidering the number of priority queues for which the variablepqfState has the value inactivePqf, the capacity allocations for allpriority queues.

Typically, the available Iub HS traffic bandwidth, that is equal to thetotal transport network capacity available for all PQFs of the RBS, canbe about 0.5 Mbps-30 Mbps. This value must be estimated in the RBS. Theminimum CA Bitrate” can typically be 8 kbps-32 kbps, this being in allpractical cases a very insignificant portion of the available Iub HStraffic bandwidth.

1. A network including a first node and a second node, wherein dataframes are transmitted from the first node to the second node, each dataframe carrying information belonging to one of a plurality of dataflows, said network comprising: a determining unit for determining, fora data flow, whether there are more data frames in the first nodewaiting to be transmitted; and, a capacity allocating unit forallocating: for a data flow for which no data frames have been waitingto be transmitted for a time period, an amount of a totally availablebitrate or bandwidth for transmission from the first node to the secondnode; and, for a remaining data flow, a share of the rest of the totallyavailable bitrate or bandwidth, for transmission from the first node tothe second node.
 2. The network according to claim 1, further comprisinga storing/setting unit connected to the determining unit for storing, atperiodically repeated times, a value for each of the data flowsindicating the result of the determining in a state indicator cell orsetting an indicator to a value indicating the result of thedetermining.
 3. The network according to claim 1, further comprising astarting/setting unit connected to the determining unit for starting, atperiodically repeated times, a timer for each of those data flows forwhich at the current time there is no data frame waiting to transmittedbut for which, at the directly previous time, there was at least onedata frame waiting to be transmitted, or setting a counter to an initialvalue.
 4. The network according to claim 3, further comprising anincrementing/changing unit for incrementing, at the periodicallyrepeated times, each of the timers already started or changing each ofthe counters by one step.
 5. The network according to claim 3, furthercomprising a comparator for comparing, at the periodically repeatedtimes, each of the timers already started or counters to a predeterminedvalue, and a changing unit for changing, for each of those data flowsfor which the result of the comparing indicates that the timer orcounter has reached or passed a predetermined value, said valueindicating the result of the determining or said indicator, and theallocating unit arranged to allocate to each of said data flows apredetermined minimum amount of the totally available bitrate orbandwidth.
 6. The network according to claim 1, wherein the first nodeis a radio network controller and the second node is a radio basestation in a universal mobile telecommunications system (UMTS), whereinthe determining unit is arranged to use information in the field “UserBuffer Size” (UBS) in data frames received by the second node.
 7. A datareceiving node for a network including a data transmitting node, thedata transmitting node transmitting data frames to the data receivingnode, each data frame carrying information belonging to one of aplurality of data flows, said data receiving node comprising: adetermining unit for determining, for a data flow, whether there aremore data frames in the data transmitting node waiting to betransmitted; and a capacity allocating unit for allocating: for a dataflow for which no data frames have been waiting to be transmitted for atime period, an amount of a totally available bitrate or bandwidth fortransmission from the first node to the second node; and, for aremaining data flow, a share of the rest of the totally availablebitrate or bandwidth, for transmission from the first node to the secondnode.
 8. The data receiving node according to claim 7, furthercomprising a storing/setting unit connected to the determining unit forstoring, at periodically repeated times, a value for each of the dataflows indicating the result of the determining in a state indicator cellor setting an indicator to a value indicating the result of thedetermining.
 9. The data receiving node according to claim 7, furthercomprising a starting/setting unit connected to the determining unit forstarting, at periodically repeated times, a timer for each of those dataflows for which at the current time there is no data frame waiting totransmitted but for which, at the directly previous time, there was atleast one data frame waiting to be transmitted, or setting a counter toan initial value.
 10. The data receiving node according to claim 9,further comprising an incrementing/changing unit for incrementing, atthe periodically repeated times, each of the timers already started orchanging each of the counters by one step.
 11. The data receiving nodeaccording to claim 10, further comprising a comparator for comparing, atthe periodically repeated times, each of the timers already started orcounters to a predetermined value, and a changing unit for changing, foreach of those data flows for which the result of the comparing indicatesthat the timer or counter has reached or passed the predetermined value,said value indicating the result of the determining or said indicator,and the allocating unit arranged to allocate to each of said data flowsa predetermined minimum amount of the totally available bit rate orbandwidth.
 12. The data receiving node according to claim 7,characterized in that it is a radio base station in a universal mobiletelecommunications system (UMTS) receiving data frames transmitted froma data transmitting node being a radio network controller, and that thedetermining unit is arranged to use information in the field “UserBuffer Size” (UBS) in data frames received by the second node.
 13. Amethod of transmitting data frames from a first node to a second node,each data frame carrying information belonging to one of a plurality ofdata flows, comprising the steps of: determining for each of the dataflows, whether there are more data frames in the first node waiting tobe transmitted; allocating, for a data flow for which no data frameshave been waiting to be transmitted for a time period, an amount of thetotally available bit rate or bandwidth; and allocating, for a remainingdata flow, a share of the rest of the totally available bit rate orbandwidth.
 14. The method according to claim 13, further comprising thestep of storing, after the step of determining whether there are moredata frames in the first node waiting to be transmitted, a value foreach of the data flows indicating the result of the determining orsetting an indicator to a state indicating the result of thedetermining.
 15. The method according to claim 13, further comprisingthe step of starting, after the step of determining whether there aremore data frames in the first node waiting to be transmitted, a timerfor each of those data flows for which at the current time there is nodata frame waiting to transmitted but for which, at the directlyprevious time, there was at least one data frame waiting to betransmitted, or setting a counter to an initial value.
 16. The methodaccording to claim 15, further comprising the step of incrementing,after the step of determining whether there are more data frames in thefirst node waiting to be transmitted, each of the timers already startedor changing each of the counters by one step.
 17. The method accordingto claim 16, further comprising the step of comparing, after the step ofdetermining whether there are more data frames in the first node waitingto be transmitted, each of the timers already started or counters to apredetermined value, and changing, for each of those data flows forwhich the result of the comparing indicates that the timer or counterhas reached or passed the predetermined value, said value indicating theresult of the determining or said indicator, and thus, allocating toeach of said data flows a predetermined minimum amount of the totallyavailable bit rate or bandwidth.
 18. The method according to claim 13,wherein the first node is a radio network controller and the second nodeis a radio base station in a universal mobile telecommunications system(UMTS), wherein in the step of determining whether there are more dataframes in the first node waiting to be transmitted, information in thefield “User Buffer Size” (UBS) in data frames received by the second isused.